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DETAILED ACTION 
Response to Amendment 

Claims 6, 28 have been cancelled. Claims 1, 7, 8, 1 1-13, 17, 23, 29-30, 33-35 and 39 have been 
amended. Claims 1-5, 7-27, 29-44 are pending. 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which the subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

1. Claims 1, 5, 6, 8-12, 14, 23, 27-28, 30-34, 36, are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Barker et al. (US Patent No: 5,675,329) in view of Tanaka (Japanese 
Patent No: JP40501 1914A). 

As for claims 1 and 23, Barker teaches of a method of processing data (Fig. 2) received 
from a keyboard (11) having a plurality of keys (11), the plurality of keys (11) including multiple 
keys (11) having respective characters assigned thereto, the plurality of keys (11) further 
including one or more force-sensing keys (12), the method comprising {claim 1 } and of a 
computer-readable medium having stored thereon data representing sequences of instructions 
which, when executed by a processor, cause the processor to perform steps comprising {claim 
23}: 
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receiving keyboard data sets reporting (110 5 120, 130, 140), for keys of the plurality 
pressed by a keyboard user, key force data and key identification data in column 3, lines 54-61; 

determining whether key force data in a keyboard data set updates key force data 
corresponding to a previously-reported key press for a key continuing to be pressed (150) in 
column 3, lines 64-67. 

generating first type keyboard data messages containing force updates based on updated 
key force data, key identifiers for the keys associated with the updated key force data, and force 
update indicators (160) in column 4, lines 1-5; and 

generating second type keyboard data messages identifying initially pressed keys and 
forces applied to the initially pressed keys (140) in column 4, lines 6-11. 

a third type keyboard data message indicating the held key has been pressed (120). 

Barker fails to teach of automatically generating at a repeat rate based on key force data 
for a key held pressed by a user. 

Tanaka teaches of automatically generating at a repeat rate based on key force data for a 
key held pressed by a user (see attached reference under the section titled "Constitution"). 

It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to combine the key force data dependent repeat rate as taught by Tanaka with the key 
force sensitive keyboard of Barker in order to "improve key operability by controlling the 
automatic repeat speed of keys on a keyboard for which automatic key repeat control is executed 
(see attached reference of Tanaka under the section titled "Purpose"). 
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As for claims 5 and 27, Barker teaches that the receiving keyboard data sets comprises 
receiving a data set having key identification data and key force data for multiple keys, and 
further comprising: 

parsing the key identification data in the keyboard data set into an ordered list of key 
identifiers; 

parsing the key force data in the keyboard data set into an ordered list of key force 
values; and 

associating key identifiers and force values based on the orders in which the key 
identification data and the key force data appear in the data set in Fig. 2 and in column 3, lines 
50-20. One can see that the key data are read into the apparatus in a certain order and identified 
in a certain order. 

As for claims 6, 8, 28, 30, Barker teaches of automatically generating, at a repeat rate 
based on key force data for a key held pressed by a user, a third type keyboard data message 
(180) indicating the held key has been pressed {claims 6, 28} and that the method of claim 6, 
wherein the automatically generating a third type keyboard data message comprises mapping a 
repeat rate to the key force data for the held key {claims 8, 30} in Fig. 2 and in column 4, lines 
1 12-22. One can see from the figure that the diagram cycles through, hence has a repeated rate. 

As for claim 9, 31, Barker teaches 
storing cumulative key force data; and 
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based on the stored cumulative key force data, mapping a repeat rate to the force data for 
the held key in Fig. 2. By comparing various key force data, one can see that the apparatus is 
able to store the cumulative key force data. Also the process shown in Fig. 2 cycles around and 
hence and a repeated rate. 

As for claims 10, 32, Barker teaches that the mapping is based on a transfer function in 
which a range of force data values is subdivided into multiple sub-ranges, and wherein each of 
the sub-ranges is assigned a repeat rate in column 3, lines 1-20. The force data has different 
ranges and values and each pertains to a certain tasks. 

As for claims 1 1, 33, the combination of Barker and Tanaka teaches that the transfer 
function comprises an initial group of sub-ranges mapped to gradually increasing repeat rate 
values followed by a group of sub-ranges mapped to a sharply increasing repeat rate values in 
column 3, lines 1-20 (Barker) and in the constitution of Tanaka. The force that the user exerts in 
pressing the buttons gradually increases in order to reach the second function of that particular 
button. 

As for claims 12, 34, the combination of Barker and Tanaka teaches of that the 
automatically generating a third type keyboard message (180) comprises: 

determining if a repeat invoke delay has elapsed since the user initially pressed the held 
key; and 
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commencing the automatic generation after the repeat invoke delay has elapsed in Fig. 2 
and in column 4, lines 1 1-25. The third type keyboard message occurs when the cycle has 
completed its repeating cycle. 

As for claim 14, Barker teaches of a method of processing data received from a keyboard 
having a plurality of keys, the plurality of keys including multiple keys having respective 
characters assigned thereto, the plurality of keys further including one or more force-sensing 
keys, the method comprising: 

receiving a keyboard data set reporting, for multiple keys of the plurality pressed by a 
keyboard user, key force data and key identification data; 

parsing the key identification data into an ordered list of key identifiers; 

parsing the key force data into an ordered list of key force values; and 

associating key identifiers and force values based on the orders in which the key 
identification data and the key force data appear in the keyboard data set Fig. 2 and in column 3, 
lines 50-20. One can see that the key data are read into the apparatus in a certain order and 
identified in a certain order. 

As for claims 21, Barker teaches of storing the identifier for the last key identified as 
pressed; 

storing the most recently received force value for the last key identified as pressed; 
receiving a keyboard data message lacking a force value and indicating that the last key 
identified as pressed remains pressed; and 
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generating a keyboard input message identifying the last key identified as pressed and 
containing the stored force value in column 3, lines 50-20. 

As for claim 36, Barker teaches of a computer-readable medium having stored thereon 
data representing sequences of instructions which, when executed by a processor, cause the 
processor to perform steps comprising: 

receiving a keyboard data set from a keyboard having a plurality of keys, the plurality of 
keys including multiple keys having respective characters assigned thereto, the plurality of keys 
further including one or more force-sensing keys, wherein the keyboard data sets report, for 
multiple keys of the plurality pressed by a keyboard user, key force data and key identification 
data; 

parsing the key identification data into an ordered list of key identifiers; 
parsing the key force data into an ordered list of key force values; and 
associating key identifiers and force values based on the orders in which the key 

identification data and the key force data appear in the keyboard data set in Fig. 2 and in column 

3, lines 50-20. 

Claims 2-4, 7, 13, 15-16, 17-21, 24-26, 29, 35, 37-43 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Barker et al. (US Patent No: 5,675,329). 

As for claims 2, 7, 24, 29 Barker teaches of a first (160) and second (140) type keyboard 
data messages in column 4, lines 1-12. 
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Barker fails to teach that the first, second and third type keyboard data messages having a 
common data structure. 

It would have been obvious to have the first, second and third type keyboard data 
messages have a common data structure in order to save money and time by having a consistent 
way to implement a similar aspect of the same apparatus. 

It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to have the first, second and third type keyboard data messages have a common data 
structure in order to save money and time by having a consistent way to implement a similar 
aspect of the same apparatus. 

As for claims 3-4, 15-16, 25-26, 37-38 Barker teaches of reported key force data 
Barker fails to teach that in determining if reported key force data contains a null 
indicator; and associating a null indicator with a non-force-sensing key {claim 3, 15, 25, 37} or 
that wherein a null indicator is a zero value for key force data {claim 4, 16, 26, 38}. 

It would have been obvious to have a way to determine if no key was pressed, or more 
specifically, if in that determining if reported key force data contains a null indicator; and 
associating a null indicator with a non-force-sensing key {claim 3} or that wherein a null 
indicator is a zero value for key force data {claim 4} so that the apparatus can detect whether or 
not a key is in use. 

It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to include that in that determining if reported key force data contains a null indicator; 
and associating a null indicator with a non-force-sensing key {claim 3} or that wherein a null 
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indicator is a zero value for key force data {claim 4} so that the apparatus can detect whether or 
not a key is in use to better monitor the keyboard pressure/force (see Barker, column 2, lines 35- 
36). 

As for claims 13, 35, Barker teaches of the method of claim 6, further comprising: 
determining if the key force data for another held key contains a null indicator; and 
upon determining that the key force data for the other held key contains a null indicator, 
automatically generating, at a preset rate and after a preset delay, repeating keyboard data 
messages indicating the other held key has been pressed in Fig. 2. It has been discussed to great 
extent above that although Barker does not teach an actual null indicator in the case where there 
is no force exerted on the button, it would have been obvious to include this feature. The rest of 
the claim limitations are taught in Fig. 2 and in column 3, lines 50-20 as one can see that this 
process is repeated through. 

As for claims 17, 39 Barker teaches of the method for processing data received from a 
keyboard having a plurality of keys, the plurality of keys including multiple keys having 
respective characters assigned thereto, the plurality of keys further including one or more force- 
sensing keys, the method comprising: 

receiving keyboard data messages identifying keys that have been pressed by a user and 
containing force values for forces applied to the pressed keys; 

generating a first keyboard input message identifying a first pressed key and containing 
the force value for the first pressed key; 
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generating a second keyboard input message identifying a second pressed key and 
containing the force value for the second pressed key and a force update indicator in column 4, 
lines 1-25. 

Barker fails to teach of receiving a registration from a first application program 
requesting keyboard input data and key force data; receiving a registration from a second 
application program requesting keyboard input data but not requesting key force data. 

However, in Fig. 2 and in column 3, lines 50-20; Barker teaches of the process that has 
various prompts to take in keyboard data because this has a similar function to the applications as 
in the claim limitations, the prompts can be seen and viewed as separate applications. 

It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to include application software with the apparatus in order to associate a different task 
or data with a different application. 

Since the apparatus of Barker is able to detect and communicate data information in 
regards to both (1) which key is pressed (see column 3, line 55) and (2) the key force data (see 
column 4, line 5); then it would be known in the art to provide an apparatus that is able to only 
send only one set of data (either the which key is pressed or the key force data). 

It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to combine only send one set of data, such as the keyboard input instead of both the 
keyboard input and the key force data in order to only provide needed data needed by various 
application to avoid unnecessary steps. 



As for claim 21, Barker teaches of: 
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storing the identifier for the last key identified as pressed; 

storing the most recently received force value for the last key identified as pressed; 

receiving a keyboard data message lacking a force value and indicating that the last key 
identified as pressed remains pressed; and 

generating a keyboard input message identifying the last key identified as pressed and 
containing the stored force value in column 3, lines 50-20. 

As for claim 22, Barker teaches of: 

receiving a simulated keyboard data message containing simulated key press data, the 
simulated key press data identifying an impressed key and containing simulated key force data 
for the impressed key; and 

generating a third keyboard input message identifying the impressed key, indicating a 
simulated key press, and containing the simulated key force value in Fig. 2 and in column 3, 
lines 50-20. 

As for claims 18, 40, Barker fails to teach of using various application, specifically 
providing the first keyboard input message to the first and second applications. 

In Fig. 2, Barker shows that there are various prompts that takes in various keyboard data. 
It would have been obvious to provide keyboard input message to first and second applications at 
these promptings in order to associate a different task or data with a different application. 
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It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to provide keyboard input message to first and second applications at these promptings 
in order to associate a different task or data with a different application. 

As for claims 19, 41, only providing the second keyboard input message to applications 
requesting key force data in Fig. 2 and in column 3,lines 50-20. 

As for claims 20, 42, Barker teaches wherein the second keyboard input message is 
provided to the first application, 

generating a third keyboard input message identifying a third pressed key and containing 
the force value for the third pressed key and a force update indicator; and 

providing the third keyboard input message to the first application prior to providing a 
message indicating that the second pressed key is no longer being pressed in Fig. 2 and in 
column 3,lines 50-20. 

As for claims 43, Barker teaches of: 

storing the identifier for the last key identified as pressed; 

storing the most recently received force value for the last key identified as pressed; 

receiving a keyboard data message lacking a force value and indicating that the last key 
identified as pressed remains pressed; and 

generating a keyboard input message identifying the last key identified as pressed and 
containing the stored force value in column 3, lines 50-20. 
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Claims 22, 44 are rejected under 35 U.S.C. 103(a) as being unpatentable over Barker et 
al. (US Patent No: 5,675,329) in view of Daniele et al. (US Patent No: 5,576,734). 

As for claims 22, 44, Barker teaches of receiving a keyboard data message containing key 
press data, the key press data identifying an impressed key and containing key force data for the 
unpressed key; and 

generating a third keyboard input message identifying the unpressed key, indicating a 
simulated key press, and containing the key force value in Fig. 2 and in column 3, lines 50-20. 

Barkers fails to teach an apparatus that is able to receive, process and generate simulated 
keyboard data. 

Daniele teaches that the keys are able to receive, process and generate simulated 
keyboard data in column 1, lines 20-25. 

It would have been obvious to one with ordinary skill in the art at the time the invention 
was made to combine the ability to receive, identify and generate simulated keyboard data as 
taught by Daniele with the force sensitive keys of Barker in order to provide other means for 
keyboard data input besides using the keyboard (see Daniele, column 1, lines 19-23). 

Response to Arguments 

Applicant's arguments with respect to claims 1-5, 7-17, 29-44 have been considered but 
are moot in view of the new ground(s) of rejection. 

As for the argument pertaining to claim 1 that there is lack of teaching of "based on key 
force data for that key that is being held pressed. In other worlds, the office action does not 
explain how the algorithm would go from block 160 to block 180 at a faster or slower rate based 
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on how much force is being applied to the key (see page 15, paragraph 1)," please refer to 
teachings of Tanaka under its constitution. 

As for the argument pertaining to claim 5 that "Barker does not teach receiving a data set 
with key identification and key force data for multiple keys (see page 16, paragraph 2)," please 
refer to Barker in column 4, line 22 where Barker teaches that the steps may be repeated for each 
key and hence multiple keys as the claim language specifies. 

As for the argument pertaining to claim 1 1 that "there is no mention whatsoever in 
Barker of such a transfer function. . . in other words, there must be at least four sub-ranges of 
force data values, with each of those sub-ranges mapped to separate repeat rate values (see page 
16, paragraph 3)," please refer to Barker and Tanaka (under constitution) where Tanaka teaches 
that the key repeat speed depends upon the pressure sensor of the key. Meaning that there are 
various rates correlating to various pressures of the user to the keys. 

As for the argument pertaining to claim 12 that "Barker does not teach or suggest that 
there is any relationship between that cycle time and the time since a key was initially pressed 
(see page 17, paragraph 1)," please refer to teachings of Tanaka under its constitution. 

As for the argument pertaining to claim 17 that "Barker does not describe sending the key 
force values to a computer, with applications without the computer then deciding how to 
interpret the key force values (see page 18, paragraph 1)," the claim language of 17 does not 
mention that the computer then decides how to interpret the key force values. 

As for the argument pertaining to claim 17 that "Barker does not teach or suggest 
receiving a data message lacking a force value (see page 18, paragraph 2)," please note that since 
Barker teaches of measuring the force data (see column 3, line 55) and recognizing which key is 
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associated with the pressed key (see column 4, line 5) it would have been obvious to one with 
ordinary skill in the art at the time the invention was made to exclude one or the other data in 
order to save time and process memory in carrying out unnecessary functions of the apparatus. 

As for the argument pertaining to claim 22 that "Barker does [not] even hint at generating 
a message regarding an unpressed key that indicated a simulated key press (see page 18, 
paragraph 3)," please refer to the teachings of Barker and Daniele (column 1 5 lines 20-25). 

Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tammy Pham whose telephone number is (571) 272-7773. The 
examiner can normally be reached on 8:00-5:30 (Mon-Fri). 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Sumati Lefkowitz can be reached on (571) 272-3638. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




Tammy Pham 
August 22, 2006 




RICHARD HJERPE 
SUPERVISORY PATENT EXAMINER 
TECHNOLOGY CENTER 2600 



